IPsec VPN
VPN Interfaces To create a VPN you need IKE and IPsec tunnels or Phase 1 and Phase 2. First start with Phase 1 or the IKE profile. You'll need an interface with layer 3 capabilities because this will be your IKE endpoint. Once you have an endpoint for Phase 1, you'll need an endpoint for Phase 2 which will be a tunnel interface. Physical Interface - IKE Gateway The gateway can be any physical interface but it has to be routed and public if it crosses the internet. You can choose an already existing interface if configured but the following command assigns an interface with an IP address. We'll assign it to the virtual router and zones later. set network interface ethernet ethernet1/11 layer3 ip 77.6.5.4/24 Tunnel Interface - IPsec Tunnel The same with the physical interface, the tunnel interface will be assigned to a virtual router and zone later. This logical interface is where we will terminate the VPN connections on the inside. The logical tunnel interface does not need an IP address unless you want to manage it. set network interface tunnel units tunnel.77 VPN Zones You will want to create a zone for the VPN termination and not use an existing zone. This is because if you do this, you will have greater flexibility when configuring rules and NAT. If you have the VPN zone the same as the outside zone and you implement a policy for your VPN users, by default it will affect the outside users not using the VPN. This is because it is in the same zone. If you do not want this behavior you will have to create a new rule to allow this traffic which is on more rule than you need if you would have set up a dedicated zone for the VPN tunnel. Outside Interface/IKE Phase 1 Gateway Add the outside interface to the untrusted zone. If the vpn-untrust zone does not exist, you can run the following command to create the zone and assign ethernet1/11 at the same time. set zone vpn-untrust network layer3 ethernet1/11 Inside Tunnel/IKE Phase 2 Add the tunnel to the inside vpn zone. You can add this interface to an existing inside zone but then you'll have a hard time with NAT and security policies just like mentioned above with the Phase 1 interface. set zone vpn-trust network layer3 tunnel.77 Virtual Router You will have to add the newly created interfaces to the virtual router and add a route towards the inside vpn-trust interface for proper routing. The static route says that if you are destined to the 10.0.1.0/24 network, go to the tunnel.77 interface to be encrypted. set network virtual-router VPN-Router interface ethernet1/11 set network virtual-router VPN-Router interface tunnel.77 set network virtual-router VPN-Router routing-table ip static-route VPN-Inside-to-Tunnel destination 10.0.1.0/24 interface tunnel.77 VPN Crypto Profiles The crypto profiles for phase 1 and 2 need to match on both sides of the VPN endpoints. If they do not match, the tunnels will not form! IKE Crypto Create a crypto policy that will be shared between the peers for the IKE Phase 1 negotiations. The firewall assigns the 'default' profile by default but you can specify your own parameters if needed. set network ike crypto-profiles ike-crypto-profiles IKE_CRYPTO_IKE_GATEWAY_1 dh-group group5 set network ike crypto-profiles ike-crypto-profiles IKE_CRYPTO_IKE_GATEWAY_1 encryption aes256 set network ike crypto-profiles ike-crypto-profiles IKE_CRYPTO_IKE_GATEWAY_1 hash sha512 set network ike crypto-profiles ike-crypto-profiles IKE_CRYPTO_IKE_GATEWAY_1 lifetime hours 8 IPsec Crypto Like the IKE Crypto, the IPsec crypto uses a default but if we wanted to define our own we can. This will be applied to the tunnel interface. set network ike crypto-profiles ipsec-crypto-profiles IPSEC_CRYPTO_IKE_GATEWAY_1 esp authentication sha512 set network ike crypto-profiles ipsec-crypto-profiles IPSEC_CRYPTO_IKE_GATEWAY_1 esp encryption aes256 set network ike crypto-profiles ipsec-crypto-profiles IPSEC_CRYPTO_IKE_GATEWAY_1 dh-group group5 set network ike crypto-profiles ipsec-crypto-profiles IPSEC_CRYPTO_IKE_GATEWAY_1 lifetime hours 8 IKE Gateway The IKE gateway is the endpoint of the IKE Phase 1. It should be the outside physical interface pointing to the net. Here you apply the IKE crypto policy along with other little buttons and bells. set network ike gateway IKE_GATEWAY_1 authentication pre-shared-key key thiskey123 set network ike gateway IKE_GATEWAY_1 local-address interface ethernet1/11 set network ike gateway IKE_GATEWAY_1 local-address ip 77.6.5.4/24 set network ike gateway IKE_GATEWAY_1 peer-address ip 44.5.6.7 set network ike gateway IKE_GATEWAY_1 protocol ikev1 exchange-mode auto set network ike gateway IKE_GATEWAY_1 protocol ikev1 ike-crypto-profile default set network ike gateway IKE_GATEWAY_1 protocol ikev1 dpd enable yes set network ike gateway IKE_GATEWAY_1 protocol ikev1 dpd interval 10 set network ike gateway IKE_GATEWAY_1 protocol ikev1 dpd retry 3 set network ike gateway IKE_GATEWAY_1 protocol-common nat-traversal enable yes set network ike gateway IKE_GATEWAY_1 protocol-common nat-traversal keep-alive-interval 10 set network ike gateway IKE_GATEWAY_1 protocol-common nat-traversal udp-checksum-enable yes IPsec Tunnel The tunnel is where we piece it all together and assign the IPsec crypto and IKE Gateway to the IPsec tunnel. Here we will also identify the proxy IDs if the other side is no a Palo Alto firewall. If the other side's internal network is 10.0.1.0/24 then we'll have to set up the proxy ID for that network if it comes from our side of 192.168.1.0/24. set network tunnel ipsec IPSEC_TUNNEL_TO_MARS tunnel-interface tunnel.77 set network tunnel ipsec IPSEC_TUNNEL_TO_MARS auto-key ike-gateway IKE_GATEWAY_1 set network tunnel ipsec IPSEC_TUNNEL_TO_MARS auto-key ipsec-crypto-profile IPSEC_CRYPTO_IKE_GATEWAY_1 set network tunnel ipsec IPSEC_TUNNEL_TO_MARS auto-key proxy-id OTHER_SIDE local 192.168.1.0/24 remote 10.0.1.0/24 VPN Security Policies Now that we have our interfaces, zones, routing, and crypto profiles we'll need to allow the traffic to pass with security policies. To make things easy, we'll allow all/all from the vpn-internal zone to the inside zone and vice versa. The log-end yes specifies that we log at the end of the session for visibility in the traffic logs. set rulebase security rules ALLOW_INSIDE_TO_VPN source any from trust to vpn-trust destination any application any service any action allow log-end yes set rulebase security rules ALLOW_VPN_TO_INSIDE source any from vpn-trust to trust destination any application any service any action allow log-end yes VPN and NAT In the above example we have the internal network of 192.168.1.0/24 going through a VPN to the remote network of 10.0.1.0/24. So from the perspective of the 10 network, they see communication from the 192 network. But what if the 10 network is expecting to communicate with a public address on the outside interface? In the following example, we'll say there is a web server sitting at 192.168.1.10 that needs to look like 77.6.5.4 as they are going through the tunnel. Create objects for these IP addresses: set address WEB-SERVER-internal ip-netmask 192.168.1.10 set address WEB-SERVER-external ip-netmask 77.6.5.4 Once these are defined we crate a NAT policy that states that any time a host from the 10 network access the web server it will reach it via the 'public' IP address. set rulebase nat rules WEB-SERVER-VPN-IN nat-type ipv4 from vpn-trust source any service any to-interface any to trust destination WEB-SERVER-external destination-translation translated-address WEB-SERVER-internal Since that is a terribly long NAT rule we can break it down as shown below: set rulebase nat rules WEB-SERVER-VPN-IN to trust set rulebase nat rules WEB-SERVER-VPN-IN destination-translation translated-address WEB-SERVER-internal set rulebase nat rules WEB-SERVER-VPN-IN from vpn-trust set rulebase nat rules WEB-SERVER-VPN-IN source any set rulebase nat rules WEB-SERVER-VPN-IN destination WEB-SERVER-external set rulebase nat rules WEB-SERVER-VPN-IN service any set rulebase nat rules WEB-SERVER-VPN-IN nat-type ipv4 set rulebase nat rules WEB-SERVER-VPN-IN to-interface any set rulebase nat rules WEB-SERVER-VPN-IN active-active-device-binding primary Testing the Configuration The big part after configuration is verification. To verify the configuration we can run some commands to 'test' the configuration as shown below. test security-policy-match Test the security policy to make sure the rulebase is correct. From the vpn-trust to the inside: